fix: use-after-free in cabi_realloc free_list on repeated export calls#319
fix: use-after-free in cabi_realloc free_list on repeated export calls#319chaynabors wants to merge 2 commits intobytecodealliance:mainfrom
Conversation
cabi_realloc tracked all allocations in Runtime.free_list, which post_call freed after each export invocation. When the host calls cabi_realloc during an import to write a return value into guest memory, those allocations may still be referenced by live JS objects across repeated export calls. post_call would free them, causing use-after-free on the next invocation. Fix: remove indiscriminate tracking from cabi_realloc. Only the retptr allocated explicitly in call() is tracked and freed by post_call. Fixes bytecodealliance#224
chaynabors
requested review from
tschneidereit and
vados-cosmonic
as code owners
|
This is a step closer to the ideal solution, but may be a partial regression in that some buffers may no longer be freed if they were copied during lifting. The lifetimes aren't clear enough to me at this point to validate this holistically. I'm trying to convince my team to adopt WASM. We can stomach a small bounded memory leak, but the current use-after-free makes Componentize unusable for us. A more comprehensive solution might involve some sort of deallocator in the splicer, but this is far more involved and risky for me to implement than the proposed solution. I'm happy to take a stab at it if I can get WASM adopted, but won't have time otherwise. |
|
Hey @chaynabors , sorry for the delay. I think this is pragmatic approach to fix double-free issue. I wonder how difficult would be to add the test that replicates #224 as part of the fix? wdyt? The next step should be to eliminate leaks by implementing proper deallocation in the splicer but that we can track in a separate issue. |
|
I think I had excluded the test because it was only reproducible under memory pressure, and because it was non deterministic, but that could have been a separate repo entirely. I'll take another look today and give an opinion. I'll need to investigate again, but will also create an issue for the leak. |
|
Summary after re-reviewing: The underlying issue is that import return buffers allocated via cabi_realloc in the splicer have no deallocation mechanism. This is now being tracked in #330. The old free_list bulk free in post_call was the only thing reclaiming them, but it also freed buffers still in use. This PR narrows post_call to only free retptrs which should be the correct behavior long term. I tried all morning to reproduce the issue in the test scaffolding but couldn't. When running my test with wasmtime directly I was able to reproduce on the first try. There's something about the jco execution environment that prevents the allocator from reusing freed regions the way wasmtime does. I don't know what that is. When running the code in the issue with wasmtime, unpatched fails and patched succeeds. Patched also succeeds a comprehensive test suite in our own code, whereas unpatched traps almost immediately with an out of bounds memory access. Happy to merge as written. I'm tuckered out. |
|
@tschneidereit Is it impolite to ask you to sanity check me here? You merged the original bookkeeping. |
2 participants
Fixes #224
cabi_realloctracked all allocations inRuntime.free_list, whichpost_callfreed after each export invocation. When the host callscabi_reallocduring an import to write a return value into guest memory, those allocations may still be referenced by live JS objects across repeated export calls.post_callwould free them, causing use-after-free on the next invocation.This PR removes indiscriminate tracking from
cabi_realloc. Only theretptrallocated explicitly incall()is tracked and freed bypost_call.retptris a temporary buffer that JS never references directly, which is why it needs to be managed explicitly.